Re: GSS API (as a DLL)...

To: Ken Shores <kss1376@pop.draper.com>
Subject: Re: GSS API (as a DLL)...
From: Icarus Sparry <I.Sparry@ss1.bath.ac.uk>
Date: Thu, 18 Aug 94 21:02:59 BST
Cc: www-security@ns1.rutgers.edu
Reply-To: I.Sparry@bath.ac.uk

>Do you see a different scenario that I missed?

I don't realy see a different senario, but I think you underestimate the
problems. When Sun added run time linking to their system it created
a whole new set of security problems, e.g. suddenly the 'sync' account
which only ran /bin/sync becomes a security problem, as people can
specify that it runs a different library than the one in /lib/libc,
and the 'login' program was not altered to deal with it.

With dynamic linking, as opposed to run time linking, then the obvious
extra problem is what happens if the server is asked to deal with
some new authenticaion method, and the program to do this is new
method is /home/icarus/gimme_root.o

Then your nice program, started at boot time or by inetd will probably just
hand over its access rights to me.

Of course you could counter with 'I am only going to allow the authentication
methods listed in this file', but then there is no advantage in dynamic
linking over runtime linking, and very little over static linking.

Standard war story. Some years ago we had a Multics system. Wonderful
system, where everything was dynamically linked. It had the standard
Adventure game on it, with access set so it could only be played between
midnight and 6am. So the systems programmers who knew what they were doing
created a 'clock' routine which said it was 3am, told the dynamic linker
to use their version rather than the standard one, and played Adventure
at any time they wanted.